सिस्टम ऋण से निपटना

प्री-एम्बल/टीएल; डॉ: मैंने हाल ही में द लॉयड ब्रौन प्रिंसिपल ऑफ एजिलिटी को एक मूर्खतापूर्ण-लेकिन-सच्चे अवलोकन के रूप में प्रकाशित किया है कि कैसे क्लासिक सीनफेल्ड लाइन "शांति अब, पागलपन बाद में" एजाइल से संबंधित है। मैंने उस पोस्ट को एक बयान के साथ समाप्त किया कि हमें बाद में आने वाले "पागलपन" के लिए बेहतर तैयारी करने की आवश्यकता है। इसे ध्यान में रखते हुए, मैं उत्पादक टीमों के निर्माण के लिए अपने दृष्टिकोण का परिचय दे रहा हूं। यह आपके सिस्टम ऋण का भुगतान करने के बारे में है।

आधुनिक तकनीक टीम टूट गई है। हम सीनियर्स पर बहुत अधिक भरोसा करते हैं, और जूनियर्स का लाभ नहीं उठाते हैं।

मैं पिछले एक साल से इस समस्या के बारे में बहुत सोच रहा हूं, क्योंकि मैंने कई टीमों को हमारे "नए सामान्य" के लिए अनुकूलित किया है। महीनों पहले, मैंने इस मामले का समर्थन करने के लिए एक लेख शुरू किया था कि भर्ती प्रबंधकों को कनिष्ठों को काम पर रखना चाहिए। एक प्रभावी तर्क देने के लिए, मुझे पता था कि मुझे एक सामान्य चिंता का समाधान करना होगा: "पहले मुझे जूनियर्स को प्रशिक्षित करने के लिए वरिष्ठों की आवश्यकता है ..." जल्दी से लेख बढ़ता गया और बढ़ता गया।

यदि आप प्रबंधन में नए हैं, तो यह प्रबंधन पर मेरा "ग्रंथ" है। यह अत्यधिक प्रभावी और उत्पादक टीमों का निर्माण करने के तरीके के बारे में है और यह कई बड़ी टीमों को सफलतापूर्वक प्रबंधित करने के एक दशक से अधिक समय पर आधारित है।

इस प्रकार एक लंबा पढ़ा जाता है - तो टीएल; डॉ है:

हम #TechnicalDebt के बारे में बहुत सारी बातें करते हैं, लेकिन तकनीकी ऋण एक बड़ी समस्या का लक्षण है जिसे मैं सिस्टम ऋण कह रहा हूँ।

नुस्खा सरल है:

1) अपने वरिष्ठों को अपने सिस्टम ऋण का भुगतान करने और काम को आसान बनाने के लिए कार्य करें।

2) किराया। जूनियर्स।

3) संघर्ष से लड़ना बंद करो। जूनियर्स औसतन 18-24 महीने रहेंगे। वे विविध अनुभव चाहते हैं। वे अन्य नौकरियों की तलाश करेंगे। एक तकनीकी समुदाय के रूप में, हम चाहते हैं कि जूनियर्स वरिष्ठता की राह पर अधिक अनुभव प्राप्त करें। यह उन्हें बेहतर बनाता है, और यह हमें बेहतर बनाता है। तो, आइए त्याग को गले लगाओ। आइए उन 18 महीनों का अधिकतम लाभ उठाने के लिए उन्हें सक्षम बनाने पर ध्यान केंद्रित करना शुरू करें, और फिर उनके अगले चरणों में उनका समर्थन करें।

कोई भी अच्छी डिलीवरी टीम प्रयोज्य पर जोर देती है। उपयोगिता को संचालित करने वाले सिद्धांत कई अलग-अलग रूपों में प्रकट होते हैं: पारेतो सिद्धांत , दादी परीक्षण , पर्याप्त अच्छे का सिद्धांत , और बहुत कुछ। और उन सभी को कुछ बहुत ही मानवीय मिलता है: क्या यह जितना कठिन होना चाहिए, उससे कहीं अधिक कठिन है?

हम इसे हर समय देखते हैं: न्यूनतम डिजाइन जो उपयोग में आसानी को प्राथमिकता देते हैं और स्पष्ट दृष्टि पर अति-केंद्रित होते हैं। बाकी सब कुछ एक व्याकुलता है, यह फूला हुआ है।

नेतृत्व, प्रबंधन, कार्य/जीवन संतुलन, और दूरस्थ/व्यक्तिगत कार्य के बारे में बात करने वाले बहुत सारे लोग हैं। हर चीज का पुनर्मूल्यांकन किया जा रहा है - और महीनों से मेरे दिमाग में यह सवाल बस इतना ही है: क्या काम करना जितना कठिन है, उससे कहीं अधिक कठिन है? यह किसी भी तरह से एक नया सवाल नहीं है, लेकिन यह एक ऐसा धागा है जो मेरे अधिकांश करियर से बुना हुआ है। मुझे कोड लिखना और उत्पादों का निर्माण करना पसंद है, लेकिन एक समग्र दृष्टिकोण से पता चल सकता है कि अधिक कोड हमेशा उत्तर नहीं होता है। अधिक कोड का अर्थ है अधिक प्रशिक्षण और रखरखाव लागत।

यदि आप एक नए प्रबंधक हैं, तो इस प्रश्न को ध्यान में रखना बहुत मूल्यवान हो सकता है। प्रबंधक बहुत कुछ के लिए जिम्मेदार हैं: आप प्रत्येक व्यक्ति की मदद कर रहे हैं - उनके डिलिवरेबल्स और उनके व्यक्तिगत लक्ष्यों को पूरा करें। आप टीम के सामंजस्य और दिशा के लिए जिम्मेदार हैं। आप अक्सर प्रक्रियाओं और नीतियों को स्थापित करने के लिए जिम्मेदार होते हैं। फिर संसाधन आवंटन और योजना बनाने के साथ-साथ पीटीओ शेड्यूल के आसपास काम करना है। लेकिन इस सब के लिए मार्गदर्शक प्रकाश वही प्रश्न है: क्या यह जितना कठिन होना चाहिए, उससे कहीं अधिक कठिन है?

पिछली बार आपने अपने आंतरिक यांत्रिकी का मूल्यांकन कब किया था? अपनी डिलीवरी टीम को एक उत्पाद के रूप में देखते हुए, आपके उपभोक्ताओं (व्यवसाय/संचालन टीम) के लिए अपने लक्ष्य को प्राप्त करना कितना आसान है? और अपने पूरे व्यवसाय को एक उत्पाद के रूप में सोचते हुए, ग्राहकों के लिए अपना व्यवसाय हासिल करना कितना आसान है?

लोगों पर ध्यान केंद्रित करते हुए, वही प्रश्न लागू होते हैं: आपकी टीम के लिए अपना काम करना कितना कठिन है? ऐसी कौन सी संरचनाएँ, रूपरेखाएँ, काल्पनिक प्रक्रियाएँ और पदानुक्रम मौजूद हैं जो आपकी दादी को इस बात पर झकझोर देंगी कि आपने कितनी जटिल चीजें की हैं?

ऋण पर एक प्राइमर

आपकी आंतरिक प्रक्रियाओं का आलोचनात्मक मूल्यांकन करने की यह पूरी विचार ट्रेन, वास्तव में, चुस्त दर्शन का एक हिस्सा है जिसे अक्सर अनदेखा कर दिया जाता है। टीमों का दावा है कि वे पूरी तरह से चुस्त हैं, या "फुर्तीली-हाइब्रिड" हैं, लेकिन करीब से देखने पर आपको पता चलता है कि उनका क्या मतलब है कि वे मैला उत्पादों को तेजी से वितरित करने के लिए असुविधाजनक कोनों को काट रहे हैं। जब सॉफ्टवेयर की बात आती है, तो किसी भी अनुभवी डेवलपर को पता चल जाएगा कि यह लगातार बढ़ते तकनीकी ऋण के लिए क्या नुस्खा बन जाता है। कोडर्स का चल रहा मजाक यह है कि आखिरी व्यक्ति ने इसे गलत किया, और यदि आप इसे सही चाहते हैं, तो आपको इसे फिर से बनाना होगा। यह आलस्य या क्षमता की कमी के कारण नहीं है। ग्रीनफील्ड का काम आसान है क्योंकि यह सभी तकनीकी ऋणों को दूर करता है - लेकिन, उन्हीं खराब प्रक्रियाओं को छोड़ दिया जाए, तो यह केवल एक बार फिर बढ़ने वाला है।

तकनीकी ऋण एक लक्षण है, और यहां तक कि जब आप इसे सक्रिय रूप से चुकाने के बारे में अच्छे हैं - तब भी आप केवल लक्षण का इलाज कर रहे हैं। यह लक्षण सोचने की गलती से आता है कि एजाइल सिर्फ सॉफ्टवेयर डिलीवरी के बारे में है।

तकनीकी ऋण की एक उचित परिभाषा है 'कार्य का संचय जिसे रिफैक्टरिंग की आवश्यकता है।' जैसा कि उल्लेख किया गया है, यह डिलीवरी पर ध्यान केंद्रित करने पर शॉर्टकट लेने से उत्पन्न होता है। जब तक आप इसे सक्रिय रूप से भुगतान नहीं कर रहे हैं, यह तेजी से बढ़ता है। बहुत अधिक तकनीकी ऋण का परिणाम भंगुरता और अस्थिरता है।

अपने सर्वोत्तम तकनीकी ऋण पर एक जानबूझकर निर्णय है: यह बाद में भुगतान करने के इरादे से कुछ क्रेडिट पर डाल रहा है। ऐसे मामलों में, तकनीकी ऋण खराब नहीं है - बशर्ते आप कर्ज चुकाने के बारे में मेहनती हों। तकनीकी ऋण का अधिक नापाक अवतार तब होता है जब आप अनजाने में ऋण में जुड़ जाते हैं, या इससे भी बदतर - आप इस बात से अनजान होते हैं कि आपने इसमें जोड़ा है।

तकनीकी ऋण प्रौद्योगिकी से संबंधित है, लेकिन प्रक्रिया ऋण की एक समान अवधारणा है - विरासत प्रक्रियाएं जो पुरानी हो गई हैं, खराब कार्य करती हैं, घर्षण पैदा करती हैं, क्रॉस-टीम गतिशीलता को प्रभावित करती हैं, या अब लागू नहीं हो सकती हैं क्योंकि भूमिकाएं बदल गई हैं। प्रक्रिया ऋण हमारी गैर-तकनीकी परिचालन कमियों को कवर करता है।

अभी भी ऋण के अन्य रूप हैं जो वितरण को प्रभावित करते हैं: डिजाइन ऋण, वास्तुकला ऋण।

बेशक, कर्ज स्वाभाविक रूप से बुरा नहीं है। जैसे आप रणनीतिक रूप से वित्तीय ऋण की एक स्वस्थ राशि ले सकते हैं, इनमें से किसी भी प्रकार के ऋण को लेना एक रणनीतिक निर्णय है। एक कार पर एक बार में 20,000 डॉलर का भुगतान करने के बजाय, आप एक ऑटो-ऋण लेते हैं और भुगतान को 10 वर्षों में फैलाते हैं। इसी तरह - आपके द्वारा उपयोग की जाने वाली तकनीक का ढेर, जिस तरह से आपने अपनी टीम के कौशल को संरचित किया है, उन भूमिकाओं की वरिष्ठता, और आपके व्यवसाय को चलाने वाली प्रक्रियाएं ऋण का एक रूप लेती हैं जो एक अवधि में चुकाया जाता है।

केवल - कभी-कभी हम इसका भुगतान नहीं करते हैं। या, इससे भी बदतर: हमें लगता है कि हम कर्ज चुका रहे हैं लेकिन हम वास्तव में और अधिक अर्जित कर रहे हैं।

परिचय: सिस्टम ऋण

मैं एक अवधारणा पेश करना चाहता हूं जिसे मैं सिस्टम डेट कहूंगा (सिस्टम्स थ्योरी के रूप में सिस्टम; सिस्टम थ्योरी पर अधिक के लिए डोनेला मीडो की शानदार थिंकिंग इन सिस्टम्स पढ़ें )।

सिस्टम ऋण ऋण के डाउनस्ट्रीम रूपों का व्यापक और मूल कारण है जो वितरण को बाधित या नकारात्मक रूप से प्रभावित करता है - चाहे व्यवसाय से निर्णयों के माध्यम से, या तकनीकी, वास्तुकला, या प्रक्रिया निर्णयों के माध्यम से। यह व्यवसाय में गणना किए गए शॉर्टकट लेने, काम को क्रेडिट पर रखने का उत्पाद है। सिस्टम डेट अपने संरचनात्मक डिजाइन के माध्यम से एक कार्य प्रणाली को बाधित करता है।

थिंकिंग इन सिस्टम्स में, मीडोज सिस्टम का एक सरल उदाहरण प्रदान करता है: एक बाथटब। सिस्टम का इनपुट नल है, आउटपुट ड्रेन है। मीडोज बताते हैं कि कैसे अलग-अलग कारक टब को कभी न भरने, रहने के स्तर या अतिप्रवाह का कारण बन सकते हैं। एक इष्टतम प्रणाली पानी का शेष स्तर है - इनपुट (नल) और आउटपुट (नाली) एक ही दर पर बहते हुए। सिस्टम ऋण सिस्टम की रचना करते समय शॉर्टकट लेने का परिणाम होगा। बाथटब सादृश्य को फैलाने के लिए, हो सकता है कि नल खराब तरीके से स्थापित हो और पानी अंततः लीक हो जाए। हो सकता है कि नाली के स्थान से कुछ क्षेत्रों में पानी जमा हो जाए, इसलिए टब कभी भी पूरी तरह से नहीं निकल सकता है। हो सकता है कि हमारे पानी को नरम करने की आवश्यकता हो और चूने का निर्माण हो।

इन मामलों में, कोई तत्काल प्रभाव नहीं है, और यह अभी भी एक इष्टतम प्रणाली बनाना संभव है - लेकिन जो छिपा है वह है ऋण का संचय जो सिस्टम को तनाव दे रहा है: लीक की भरपाई के लिए नल को तेजी से बहना पड़ता है, या नल धीमी गति से बहता है और टब को भरने में अधिक समय लगता है।

यदि आप मीडोज की पुस्तक से परिचित हैं - तो उसके कई उदाहरण वास्तविकता में निहित हैं और मॉडल आमतौर पर एक स्थिर दृष्टि प्रदान करते हैं; सिस्टम समय के साथ नहीं बदलता है। यह उसके उद्देश्यों के लिए एकदम सही है, लेकिन जब व्यक्तियों, टीमों, संचालन और व्यवसायों की बात आती है, तो हम आज नहीं हैं कि हम कल कौन होंगे।

सिस्टम ऋण को थोड़े अलग तरीके से परिभाषित करने के लिए:

सिस्टम ऋण = सिस्टम सिद्धांत + परिपक्वता मॉडल

सॉफ़्टवेयर टीमों के साथ, आप सिस्टम ऋण को कुछ तरीकों से प्रकट होते देखते हैं:

• समय के साथ, यदि अप्रबंधित छोड़ दिया जाता है, तो टीमें अधिक से अधिक "आदिवासी ज्ञान" विकसित करती हैं। ये सुविचारित आदतों, शॉर्टकट और वर्कअराउंड के रूप में दिखाई देते हैं। क्योंकि वे अल्पकालिक दक्षता पैदा करते हैं, इसलिए उनके परिणामस्वरूप दीर्घकालिक कमियों की अनदेखी की जाती है। यदि इसका भुगतान नहीं किया जाता है, तो नियमित रूप से छोड़ने के माध्यम से ज्ञान हानि का एक स्पष्ट जोखिम है। इससे उत्पादकता में कमी आती है क्योंकि टीमों को धुरी और रैंप पर चलना पड़ता है। ("जो यह जानता था, लेकिन अब जब वह चला गया है - हमें इसका पता लगाने में समय बिताना होगा।") या अपरिचितता के कारण तकनीकी ऋण का संचय। ("हम उस घटक को अपडेट नहीं कर सकते। सैली ने इसे बनाया, और जब भी हम इसे छूते हैं, यह टूट जाता है...")
• टीमें कस्टम डिजाइन पैटर्न, अनौपचारिक विकास नियमों या समझौतों पर भरोसा करेंगी जो स्थानीय प्रवाह को अधिकतम करते हैं, लेकिन वे पैटर्न बदलने के लिए भंगुर हैं। यह वितरण में बाधा डालता है जब कुछ स्थापित पैटर्न के साथ संरेखित नहीं होता है, तो व्यावसायिक टीम को तकनीकी निर्णयों के लिए बंधक बना दिया जाता है। ("हम एक कस्टम इंस्टेंस को स्पिन नहीं कर सकते - हमने इसे कभी इस तरह से डिज़ाइन नहीं किया है।")
• विघटनकारी पूर्वव्यापी पर यथास्थिति बनाए रखने पर आत्मसंतुष्ट होने वाली टीमों को प्राथमिकता दी जाती है। वे अभी भी पूर्वव्यापी हो सकते हैं, लेकिन अगर उन्होंने वास्तविक समस्याओं को दूर करने की क्षमता में विश्वास खो दिया है, तो वे केवल तुच्छ चीजों को ठीक करने पर ध्यान केंद्रित करेंगे। ("हम घटना अनुरोधों के साथ अतिभारित हो रहे हैं, लेकिन जो कुछ भी - हमें बस उन्हें हल करना होगा मुझे लगता है ...")
• पता योग्य घर्षण के बावजूद एक स्थायी गति से टकराने के साथ आने वाली अस्वस्थता या उदासीनता। स्थायी गति दक्षता की झूठी भावना पैदा करती है। ("क्या हमें वास्तव में प्रक्रिया को बदलने की आवश्यकता है? हमने अपनी प्रगति पर प्रहार किया है - इसे बाधित क्यों करें?")

उत्पाद और संचालन टीमों के साथ, आप सिस्टम ऋण को इसी तरह देखते हैं:

• "हर ग्राहक कॉल एक फायर अलार्म है" शॉर्टकटिंग, विकास टीम को जल्दी से मामूली मुद्दों को जल्दी से ठीक करने के लिए देरी रिलीज, कम वेग, आदि ("मुझे एक चिड़चिड़े ग्राहक द्वारा उठाए गए मुद्दे को देखने के लिए टीम की आवश्यकता है, यह होगा केवल 20 मिनट का समय लें...")
• लास्ट-पर्सन-आई-स्पोक-टू-इज-माय-हाई-प्रॉरिटी अराजकता टीम को लगातार संदर्भ बदलने के लिए मजबूर करती है और एक समस्या पर पूरा ध्यान केंद्रित नहीं कर सकती है।
• जब प्राथमिकता देना भ्रामक मेट्रिक्स के उपयोग के माध्यम से एक शॉर्टकट है। उदाहरण के लिए, उच्च-डॉलर का ग्राहक जो अब व्यावसायिक उद्देश्यों के अनुरूप नहीं है। वे आपके शुरुआती दिनों में समझ में आए, लेकिन जैसे-जैसे व्यवसाय परिपक्व होता गया, वही ग्राहक और अधिक समस्याग्रस्त हो गया। ("हम नहीं जानते कि हम इस ग्राहक को बनाए रखना चाहते हैं या नहीं, लेकिन वे हमें बहुत अधिक भुगतान करते हैं इसलिए हमें इसे करने की आवश्यकता है ...")

दोहराना: सभी प्रकार के ऋण तब होते हैं जब हम इसे बाद में ठीक करने के इरादे से एक शॉर्टकट लेने का चुनाव करते हैं। तकनीकी ऋण तब होता है जब हम कोड के साथ ऐसा करते हैं। प्रक्रिया ऋण तब होता है जब हम इसे अपनी औपचारिक प्रक्रियाओं के साथ करते हैं। सिस्टम ऋण तब होता है जब हम इसे संगठनात्मक स्तर पर करते हैं। मैं इसे 'संगठनात्मक ऋण' के बजाय 'सिस्टम ऋण' के रूप में देखना पसंद करता हूं क्योंकि संगठन को एक प्रणाली के रूप में सोचने का मतलब है कि तकनीकी, प्रक्रिया, डिजाइन ऋण सभी सीधे सिस्टम ऋण के कारण होते हैं। वे कारक जो हमें तकनीकी ऋण लेने के लिए प्रेरित करते हैं, अंततः सिस्टम ऋण से संबंधित हैं। ("आप इतने लोगों को नदी में डूबने से बचा सकते हैं, इससे पहले कि आप ऊपर की ओर देखना शुरू करें, यह निर्धारित करने के लिए कि वे क्यों गिरते रहते हैं।")

एक उदाहरण के रूप में: विकास दल एक नई सुविधा जारी कर रहा है जिसकी उचित योजना और लागत थी। टीम ट्रैक पर है लेकिन अंतिम चरण में एक ऐसे मुद्दे का सामना करना पड़ता है जो एक खतरनाक प्रश्न को मजबूर करता है: मुद्दे को ठीक से संबोधित करके रिलीज में देरी करें या नंगे-न्यूनतम फिक्स करें और फिर इसे अगले पुनरावृत्ति में ठीक से हल करें? वे तकनीकी ऋण लेने का चुनाव करते हैं: "हम इसे अगले पुनरावृत्ति पर प्राप्त करेंगे।"

यह वह जगह है जहां सिस्टम ऋण समीकरण में प्रवेश करना शुरू करता है। क्या टीम वास्तव में इसे संबोधित कर पाएगी? क्या टीम रिफैक्टर के लिए पर्याप्त रूप से कुशल है? क्या व्यवसाय जवाब देगा "यह काफी अच्छा है, हमें आगे बढ़ने की जरूरत है"? क्या भविष्य की लागत से पता चलेगा कि अब सही तरीके से करना बहुत महंगा हो गया है? क्या प्राथमिकताओं में बदलाव, या अत्यावश्यक मुद्दों में उछाल, अचानक किसी अन्य पुनरावृत्ति द्वारा ठीक करने में देरी करेगा? फिर एक और पुनरावृत्ति, फिर दूसरा ...

इसके अतिरिक्त, ऊपर की ओर देखना: समस्या का सामना करने में इतना समय क्यों लगा? क्या गलत धारणाएँ बनाई गईं? क्या वे बुरी धारणाएँ थीं? हमेशा ऐसा मुद्दा होता है जिसे आप खेल में देर तक निर्धारित नहीं कर सकते - लेकिन फिर यह रिलीज में देरी का सवाल क्यों बन गया? क्या वादे बहुत जल्दी किए गए थे? क्या कोई बड़ा बफर होना चाहिए था? यदि व्यक्ति ए (अपस्ट्रीम बिजनेस सेल्सपर्सन) ने सबसे छोटी श्रृंखला के बाद व्यक्ति एफ (डाउनस्ट्रीम डेवलपर) से अधिक बात की तो क्या इसका समाधान हो गया होगा?

एक और सर्व-परिचित उदाहरण बुनियादी ढांचे, वास्तुकला और होस्टिंग मॉडल के साथ आता है, जिसे हम 3-5 वर्षों में व्यवसाय के पैमाने पर आधारित धारणाओं के आधार पर खुद को जल्दी से बंद कर लेते हैं। एक छोटी सी टीम सर्वोत्तम DevOps सिद्धांतों का पालन करने के बजाय तेजी से वितरण के पक्ष में बुनियादी ढांचे और वास्तु ऋण को जल्दी से लेने का चुनाव कर सकती है।

बेशक, विशिष्टताओं के बिना इस तरह के परिदृश्यों को चित्रित करना आसान है - लेकिन उन विशिष्टताओं के लिए विशिष्टताओं और बहाने की परवाह किए बिना: सिस्टम ऋण अर्जित होगा। यह अपरिहार्य है। यह ठीक है - इसे केवल निरंतर ध्यान देने की आवश्यकता है और इसे बनाए रखने योग्य स्तरों तक भुगतान करने पर केंद्रित है।

क्षतिपूर्ति शॉर्टकट

हम कर्ज लेते हैं - सिस्टम या अन्यथा - एक शॉर्टकट के रूप में। सिस्टम ऋण में गहराई से जाने से पहले और इसे कैसे चुकाना है, आइए पहले एक कदम पीछे हटें और पूछें कि हम शॉर्टकट क्यों ले रहे हैं? ऋण की तरह ही शॉर्टकट भी स्वाभाविक रूप से खराब नहीं हैं - लेकिन उनका बारीकी से विश्लेषण किया जाना चाहिए।

भौतिक शॉर्टकट के बारे में सोचना शुरू करने का एक शानदार तरीका है। यदि आप कभी पैदल या साइकिल चालक रहे हैं, तो आपने निश्चित रूप से देखा है कि पहले वाहनों के लिए चीजें कैसे डिजाइन की जाती हैं, पैदल चलने वालों के लिए। जब आप चलते हैं, तो आप कई "शॉर्टकट" लेते हैं और सड़कों का अनुसरण नहीं करते हैं - लेकिन निश्चित रूप से, ये शॉर्टकट नहीं हैं। ये शॉर्टकट एक पैदल यात्री के लिए क्रो-फ्लाई इष्टतम पथ हैं जो वहां जा सकते हैं जहां कारें नहीं जा सकतीं। वास्तव में, मुख्य रूप से पैदल-भारी क्षेत्रों में कारों के लिए हमारे मार्गों का निर्माण सिस्टम ऋण का [दूसरा रूप] (दूसरा रूप) है।

व्यापार की दुनिया में, हम समय की कमी, बजट की कमी, संसाधनों की कमी, जवाबदेही की कमी, या व्यापक दृष्टिकोण की कमी के लिए क्षतिपूर्ति करने के लिए शॉर्टकट लेते हैं। समय, बजट और संसाधन सभी को सुर्खियों में मिलता है - लेकिन जवाबदेही और व्यापक परिप्रेक्ष्य मेरे शुरुआती प्रश्न के केंद्र में हैं: क्या यह जितना कठिन होना चाहिए, उससे कहीं अधिक कठिन है? जब आप लोगों को नदी में डूबने से बचा रहे हैं, तो यह उस नज़र को ऊपर की ओर (व्यापक परिप्रेक्ष्य) ले रहा है और उस व्यक्ति (जवाबदेही) की ओर इशारा कर रहा है जो लोगों को अंदर धकेलता रहता है।

दूसरे शब्दों में: यदि आप सिस्टम ऋण के बारे में गंभीर बातचीत करने जा रहे हैं, तो सभी को बातचीत का हिस्सा बनने की जरूरत है। स्थानीय प्रयास केवल इतना ही मिलता है।

तो आप सिस्टम ऋण का भुगतान कैसे करते हैं?

आइए पहले के उस प्रश्न पर वापस आते हैं: आपकी डिलीवरी टीम के लिए डिलीवरी करना कितना आसान है? यदि आपने इस प्रश्न पर कभी विचार नहीं किया है, तो कुछ मीट्रिक प्राप्त करने का समय आ गया है! जरूरी नहीं कि ये मेट्रिक्स आपको उत्तर दें, लेकिन वे एक महत्वपूर्ण प्रारंभिक बिंदु हैं। जब KPI की बात आती है, तो मुझे अब तक मिली सबसे अच्छी सलाह यह थी कि एक व्यक्ति KPI न तो बुरा है और न ही अच्छा है। यह वस्तुनिष्ठ रूप से सिर्फ एक संख्या है, एक मूल्य है। यह हमेशा की तरह आपका व्यवसाय है - और आपको यह तय करना है कि आप उस संख्या को ऊपर या नीचे समायोजित करना चाहते हैं या नहीं। यदि आप ओकेआर सिस्टम या स्मार्ट लक्ष्यों के प्रशंसक हैं, तो यह बहुत अच्छा है क्योंकि अपने केपीआई को जानने से आप बेहतर ओकेआर बना सकते हैं जो आसानी से निर्धारित हो जाते हैं।

तो आइए कुछ बुनियादी बातों के साथ शुरुआत करें और मातम में उतरें। आगे जो है वह एक विस्तृत सूची नहीं है, और आपके समूह के लिए उपयुक्त बेहतर प्रश्न हो सकते हैं। इस सूची को बेहतर प्रश्न पूछने के लिए शुरुआती बिंदु के रूप में सोचें।

वितरण:

• उच्च-प्राथमिकता/अत्यावश्यक वस्तुओं के लिए आपका लीड और साइकिल समय क्या है?
• निम्न-प्राथमिकता वाली वस्तुओं के लिए आपका लीड और साइकिल समय क्या है?
• आपने कर्ज चुकाने के लिए कितना आवंटित किया है?
• आपका कर्ज कितना बढ़ रहा है?

ये प्रश्न किसी को भी परिचित लग सकते हैं जो अपनी टीम के प्रदर्शन को ट्रैक करते हैं - लेकिन संगठन स्तर पर इन्हें पूछना याद रखें। डेवलपर का लीड टाइम भले ही टिकट बनने के समय से शुरू हो गया हो - लेकिन यह किसी के दिमाग में कब तक रहा?

संसाधन:

• आपकी वर्तमान टीम ब्रेकडाउन (सीनियर बनाम जूनियर) क्या है?
• सीनियर्स और जूनियर्स में नौकरी छोड़ने का आपका जोखिम क्या है?
• किसी वरिष्ठ को खोने की कीमत क्या है?
• एक जूनियर को खोने की कीमत क्या है?
• काम पर रखने की लागत और अवधि क्या है?
• आपके साक्षात्कार/ऑन-बोर्डिंग की अवधि कितनी है?
• आपके प्रशिक्षण/रैंप-अप की लंबाई क्या है (और किन संसाधनों को शामिल करने की आवश्यकता है, और इसलिए उत्पादकता कम हो जाती है?)

बिजनेस बैकलॉग:

• यह मानते हुए कि उत्पाद प्रबंधक के रणनीतिक ढांचे को परिभाषित किया गया है, कितने अपवाद बनाए गए हैं?
• कितने महाकाव्य/विशेषताएं वित्तीय और समय-सीमा दोनों से जुड़े वस्तुनिष्ठ रूप से परिभाषित व्यावसायिक मामलों में निहित नहीं हैं?
• बिक्री/व्यवसाय देव पाइपलाइन अंततः आपके सॉफ़्टवेयर बैकलॉग में कैसे फीड होती है, और उनके लिए लीड और साइकिल का समय क्या है?
• उच्च-स्तरीय व्यावसायिक उद्देश्य कितनी बार बदलते हैं, और यह अराजकता डाउनस्ट्रीम प्रयासों को कितना प्रभावित करती है?
• व्यवसाय के दीर्घकालिक विकास उद्देश्य क्या हैं, और टीम का कौशल और संसाधन योजना कैसे संरेखित होती है?

संचालन बैकलॉग

• प्रतिदिन कितने ग्राहक मुद्दे उठाए जाते हैं?
• टियर 1, 2, 3 सपोर्ट पर जाने के लिए कितने ग्राहक मुद्दों की आवश्यकता है?
• संकल्प के लिए औसत समय क्या है?
• ग्राहक के मुद्दे के लिए प्रमुख समय क्या है, और प्रारंभिक कॉल से विकास टिकट कब तक बनाया जाता है?

शुरुआत से लेकर उपलब्धता तक किसी चीज़ को जाने में कितना समय लगता है, इसका एक सरल अर्थ प्राप्त करना बहुत ही ज्ञानवर्धक हो सकता है - खासकर जब यह ग्राहक की समस्या हो।

ऐसे कई संसाधन हैं जो उपरोक्त मेट्रिक्स को बेहतर बनाने में मदद करते हैं - लेकिन इन सबके पीछे मुख्य दर्शन है: 1) मापें, 2) विश्लेषण करें, 3) समाधान करें, 4) पुनरावृति करें। टियर 3 जितनी अधिक समस्याएं टियर 2 में उतारी जा सकती हैं, टियर 2 से टियर 1 तक उतनी ही अधिक टियर 1 ग्राहक को स्वतंत्र रूप से हल करने में सक्षम कर सकती है और हर कोई अधिक उत्पादक बन जाता है।

डेवलपर्स:

• स्रोत को हथियाने और निर्माण करने में उन्हें कितना समय लगता है?
• आप कितनी जल्दी नए डेवलपर्स को क्रेडेंशियल प्रदान करते हैं?
• वे कितनी जल्दी खड़े हो सकते हैं और काम करने वाले निचले वातावरण के साथ बातचीत कर सकते हैं?
• डेवलपर को उत्पादन के लिए कोड जारी करने में कितना समय लगता है (उनकी किराया तिथि से मापा जाता है)?
• आपके एसडीएलसी और प्रक्रियाओं पर रैंप-अप करने में कितना समय लगता है?
• यदि वे मध्य स्प्रिंट शुरू करते हैं, तो वे कितने समय तक किनारे पर बैठते हैं?
• कुल मिलाकर, आपका वर्तमान सीखने की अवस्था क्या है?

तुलना के लिए: Etsy दक्षता का एक बेहतरीन उदाहरण है और एक बेहतरीन बेंचमार्क बनाता है। Etsy सुनिश्चित करता है कि डेवलपर्स अपने पहले दिन उत्पादन के लिए तैनात हों ।

समग्र दृष्टिकोण:

• शुरुआत से उपलब्धता तक डिलीवरी की यात्रा क्या है? वर्कफ़्लो को मैप करें - क्या इसे अनुकूलित किया जा सकता है?
• बिक्री से राजस्व (और उससे आगे) तक ग्राहक की यात्रा क्या है?
• आरपीओ और आरटीओ क्या हैं?
• एक्सेलरेट: द साइंस ऑफ लीन सॉफ्टवेयर और देवओप्स में वर्णित उच्च वितरण प्रदर्शनकर्ताओं की तुलना में व्यावसायिक प्रदर्शन की तुलना कैसे होती है?
• शीर्ष 10 दुःस्वप्न आपदा परिदृश्य क्या हैं? यह कुछ ऐसा है जिसे FedEx ने अपने संचालन में सुधार करने और उन्हें आज की कंपनी बनाने के लिए एक आंतरिक 'प्लेबुक' बनाने के लिए किया है।

उपरोक्त के पीछे सभी नंबरों और मीट्रिक को देखते हुए, मैं दोहराता हूं कि इनमें से कोई भी संख्या हमेशा की तरह आपके व्यवसाय का प्रतिनिधित्व करती है। हालांकि वे आंतरिक रूप से खराब या अच्छे नहीं हैं, सिस्टम डेट इन नंबरों को लंबे समय तक बनाए रखना कठिन बना देता है। कुछ संख्याएं आश्चर्यजनक हो सकती हैं और उन क्षेत्रों को प्रकट कर सकती हैं जहां इस तरह के ऋण का पहले से ही प्रभाव हो सकता है।

अगला कदम यह विचार करना है कि ये मीट्रिक समय के साथ कैसे बदलते हैं - जैसे-जैसे आप परिपक्व होते हैं और परिपक्व होते रहते हैं। एक उदाहरण के रूप में - मुख्य उत्पाद का निर्माण करने वाले इंजीनियरों ने आपको एक ऐसे आर्किटेक्चर में बंद कर दिया है जो इसकी मापनीयता की सीमा के करीब है। इन मामलों में, टीमें देखती हैं कि वे तकनीकी ऋण का भुगतान कैसे कर सकती हैं - लेकिन सिस्टम ऋण के बारे में क्या? संसाधनों के सीमित सेट, नौकरी छोड़ने के बढ़ते जोखिम और परिपक्व होने वाले व्यवसाय को देखते हुए - आप तकनीकी ऋण का भुगतान करते हुए डिलीवरी KPI को कैसे बनाए रखते हैं?

'किल योर डार्लिंग्स,' फायर योर 'रॉक स्टार्स,' अपनी 'हिडन फैक्ट्रियों' को नष्ट करें, मददगार बनना बंद करें

वे एक शीर्षक में बोल्ड स्टेटमेंट का एक समूह हैं। इस सब में बात यह है कि: किसी प्रक्रिया को शॉर्टकट करने के लिए "सहायक" होना खतरनाक हो सकता है। अगर हम इस विचार की सदस्यता लेते हैं कि "जो मापा जाता है, हो जाता है" सहायक होने के साथ समस्या यह है कि इसे अक्सर मापा नहीं जाता है ।

कल्पना कीजिए कि कोई ग्राहक कॉल कर रहा है क्योंकि उसने बहुत तेज़ी से आगे बढ़ने पर गलती से अपने पोर्टल में एक रिकॉर्ड हटा दिया है। उनके पास समय की कमी है - और वे किसी रिकॉर्ड को पुनर्स्थापित करने की प्रक्रिया से नहीं गुजर सकते। वे कॉल करते हैं और आपका ग्राहक सहायता कर्मचारी, मददगार बनना चाहता है, तुरंत डेटाबेस इंजीनियर के पास जाता है, जो मददगार बनना चाहता है, तुरंत रिकॉर्ड को पुनर्स्थापित करता है। ग्राहक रोमांचित है, एनपीएस स्कोर ऊपर जाता है। सब कुछ बढ़िया है, है ना?

किसी के उत्पादन डेटाबेस को एक पल के लिए अद्यतन करने के स्पष्ट जोखिमों को अनदेखा करते हुए, बहुत सी मूल्यवान जानकारी है जो सहायक होने में खो जाती है:

• इतनी नाटकीय कार्रवाई करना इतना आसान क्यों है कि ग्राहक ने पहली बार में गलती की?
• नाटकीय कार्रवाई को पूर्ववत करना इतना कठिन क्यों है कि उन्हें बुलाना पड़ा?
• ग्राहक सहायता इसे क्यों नहीं संभाल पाई?
• सहायक और संदर्भ-स्विचिंग होने का परिणाम क्या उत्पादकता प्रभाव था? (एक साधारण 20-मिनट का कार्य 35 मिनट से अधिक का होता है क्योंकि इसे उत्पादक प्रवाह में वापस आने में समय लगता है।)

आइए स्पष्ट करें: मेरा शीर्षक बोल्ड है। लेकिन, मैं किसी ग्राहक की सहायता करने की वकालत नहीं कर रहा हूं - हालांकि, मुझे लगता है कि इस तरह की कार्रवाइयों का कुछ मूल कारण विश्लेषण के साथ पालन किया जाना चाहिए। कुछ भी औपचारिक नहीं है - लेकिन भविष्य में इसी तरह की समस्या से बचने के लिए कुछ।

एक संगठन में, मैंने केवल एक प्लेबुक लागू करके अपनी विकास टीम की उत्पादकता में 50% तक सुधार किया। एक ग्राहक कॉल करता है और ग्राहक सहायता प्रतिनिधि द्वारा उनका विनम्रतापूर्वक स्वागत किया जाता है जो समाधान की दिशा में एक स्पष्ट कार्यप्रवाह का अनुसरण करता है। अगर वे इसे हल नहीं कर सकते हैं, तो हमारे पास फीडबैक लूप है ताकि वे केवल एक बार किसी मुद्दे को बढ़ा सकें। परिणाम एक अधिक सक्षम और कुशल ग्राहक सहायता टीम, कम रुकावटों वाली एक विकास टीम, समग्र रूप से कम तनाव - और, महत्वपूर्ण रूप से, खुश ग्राहक थे।

मुद्दा यह है कि जब छाया में सहायक कार्य होता है, तो आप मूल कारण को ठीक नहीं कर सकते।

हम रॉक स्टार डेवलपर के साथ भी यही समस्या देखते हैं, जो कम-कुशल टीम के लिए बहुत अधिक काम और जिम्मेदारी लेता है - केवल उनके लिए निराश होना, जल जाना, और छोड़ना (एक लागत जो विनाशकारी हो सकती है)। विल लार्सन की महान पुस्तक - ए एलिगेंट पज़ल - आपके "रॉक स्टार्स" को संभालने का एक अच्छा काम करती है।

जूनियर्स की ताकत...

वरिष्ठ एक संगठन और उत्पाद की सफलता के लिए महत्वपूर्ण हैं - लेकिन वे समान रूप से सबसे बड़े जोखिमों में से एक हैं।

उदाहरण के लिए, एक वरिष्ठ डेवलपर को कोड आधार के माध्यम से और उसके माध्यम से पता चल जाएगा। वे जानते हैं कि क्या प्रलेखित है और क्या नहीं है। उन्हें पता चल जाएगा कि यह कहां अच्छा है और कहां टूटता है। उन्हें पता चल जाएगा कि कंकाल कहां दफन हैं। हम अक्सर उनके पास जाते हैं - सुविधाओं के निर्माण और डिजाइन के लिए उन पर भरोसा करते हैं, आर्किटेक्ट समाधान करते हैं, और सबसे कठिन बग को हल करने में मदद करते हैं। वे ज्ञान गुरु हैं जो किसी भी प्रश्न का उत्तर दे सकते हैं। वे कनिष्ठ कर्मचारियों को प्रशिक्षित और सलाह देते हैं और समाधान विकसित करते समय उनसे परामर्श किया जाता है।

यह कहने के लिए पर्याप्त है, वरिष्ठ कर्मचारियों से बहुत कुछ पूछा जाता है। यह एक स्पष्ट बयान है, उनके अनुभव और शायद संगठन की सफलता में निहित स्वार्थ को देखते हुए। हालाँकि, मैं प्रस्तुत करता हूँ, कि यह वह जगह है जहाँ हम सबसे अधिक सिस्टम ऋण लेते हैं।

कोई भी वरिष्ठ स्टाफ सदस्य जो सुपुर्दगी की प्रगति करता है वह एक शॉर्टकट है जो सिस्टम ऋण अर्जित करता है।

मैं दोहराऊंगा क्योंकि गलत व्याख्या करना आसान है। आपके पास एक डिलिवरेबल पर टीम का एक वरिष्ठ सदस्य काम कर सकता है, लेकिन आपको उस ऋण का भुगतान करने की योजना बनानी चाहिए जो ऐसा करने में अर्जित होगा।

डिलिवरेबल्स के लिए सीनियर्स पर भरोसा करना एक टूटा हुआ मॉडल है - विशेष रूप से आज की दुनिया में जहां कई जूनियर्स और स्किल्ड एंट्री-लेवल के उम्मीदवार हैं, और इंटरमीडिएट से सीनियर एट्रिशन का जोखिम उच्च और महंगा दोनों है।

रिमोट वर्चुअल वर्कफोर्स ने किसी भी संगठन के लिए सीनियर-स्टाफ के प्रभाव को कम करते हुए जूनियर / इंटरमीडिएट टीम को ऊपर उठाने के लिए इसे और अधिक महत्वपूर्ण बना दिया है। इसका मतलब वरिष्ठ कर्मचारियों को कम करना नहीं है, लेकिन इसका मतलब दृष्टिकोण में संरचनात्मक अंतर है।

एक सामान्यीकरण का उपयोग करते हुए, आज की सीनियर टीमें सिस्टम के पीछे की जटिलताओं के लिए काफी हद तक जिम्मेदार हैं: उनका अनुभव और विशेषज्ञता परिपक्व सिस्टम का उत्पादन करती है, और छोटे कार्य-आधारित घटक अधिक जूनियर टीम के सदस्यों द्वारा कार्यान्वित किए जाते हैं।

यह ठीक वही मॉडल है जो टीम के वरिष्ठ सदस्य के जाने पर समस्याग्रस्त साबित होता है, और सिस्टम ऋण अर्जित करने वाली संरचना भी। इस स्थिति में, सीनियर जटिलताओं के लिए ज़िम्मेदार है और जब जूनियर टीम डिलीवर नहीं कर सकती (उदाहरण के तौर पर "रॉक स्टार" डेवलपर)।

यह समस्या मौजूदा कर्मचारियों के छोड़ने की दर से और बढ़ जाती है: उदाहरण के लिए, राष्ट्रीय स्तर पर जूनियर डेवलपर्स 18-24 महीने (बड़ी फर्मों में लंबे समय तक) के लिए एक भूमिका में रहेंगे। दूसरे शब्दों में, जब तक एक जूनियर एक ऐसे बिंदु पर पहुँचता है जहाँ वे अधिक महत्वपूर्ण योगदान देना शुरू कर सकते हैं, वे अपने रास्ते से हट जाते हैं।

संगठन वरिष्ठ कर्मचारियों को बनाए रखने के लिए लड़ेंगे, जूनियर कर्मचारियों को बनाए रखने के लिए (कुछ हद तक) लड़ेंगे - और लगातार ज्ञान की कमी से पीड़ित हैं। अंततः, यह एक हारी हुई लड़ाई है - भले ही कर्मचारियों को बनाए रखा जाए, या टीम के नए सदस्य शामिल हों, वे अब सिस्टम ऋण की एक बड़ी राशि का भुगतान करने की स्थिति में हैं।

अच्छे काम को आसान बनाएं और अपरिहार्य को अपनाएं

एक छोटे से मिशेलिन-तारांकित रेस्तरां की कल्पना करें। रसोइयों की एक टीम के बीच वितरित करने के लिए व्यंजन बहुत जटिल होने के साथ, प्रधान रसोइया प्लेटों के निर्माण में बहुत शामिल होता है। शेफ इस मामले में रेस्टोरेंट है।

व्यापक फ्रैंचाइज़ी रेस्तरां के साथ इसकी तुलना करें। आपके पास कॉरपोरेट में एक हेड-शेफ बैक है, जिसकी जिम्मेदारी ग्राहकों द्वारा खाए जाने वाले व्यंजन का उत्पादन नहीं करना है। इसके बजाय, उनका लक्ष्य प्रतिलिपि प्रस्तुत करने योग्य व्यंजन तैयार करना है। ऐसे व्यंजन जिन्हें आसानी से पुन: उत्पन्न किया जा सकता है (जबकि अभी भी स्वादिष्ट हैं)। ऐसे व्यंजन जिन्हें अनुकूलित किया जाता है ताकि सीखने की अवस्था न्यूनतम हो - नए रसोइयों को व्यंजन बनाने के लिए आसानी से प्रशिक्षित किया जा सकता है, और उनके अंतिम प्रस्थान का नुकसान कम प्रभावशाली होता है। फ्रैंचाइज़ी किचन को डिलीवरी के लिए कैसे अनुकूलित किया जा सकता है, यह देखने के लिए हेड शेफ दक्षता विशेषज्ञों के साथ भी साझेदारी करते हैं।

जब हम आधुनिक टीम के बारे में सोचते हैं तो हमें इस मॉडल का उपयोग करना चाहिए। वरिष्ठ टीम की जिम्मेदारी उत्पाद की जटिलता नहीं होनी चाहिए। यह पूरी तरह से वितरण को सरल बनाने पर केंद्रित होना चाहिए: प्रशिक्षण और रैंप-अप को सरल बनाना, समय निर्धारित करना, समय बनाना, लीड और साइकिल समय को सुव्यवस्थित करना (बोर्ड भर में, बिक्री / उत्पाद समाधान से, पुनरावृत्ति योजना के माध्यम से, रिलीज तक)।

आप चीजों की संरचना कैसे करेंगे यदि आप जानते हैं कि आप केवल 18 महीने के लिए लोगों को बनाए रख सकते हैं? वास्तव में, आप चीजों की संरचना कैसे करेंगे यदि आप उन्हें 18 महीने के अनुबंध पर रखते हैं, अंत में एक कठिन समाप्ति के साथ? आप चाहते हैं कि रैंप-अप यथासंभव तेज और छोटा हो। आप चाहते हैं कि आपके विशेषज्ञों की टीम यह सुनिश्चित करे कि आपके नए कर्मचारियों को सप्ताहों में बढ़ाया जा सकता है ताकि वे प्रभाव को अधिकतम कर सकें। आप यह सुनिश्चित करना चाहते हैं कि आपके विशेषज्ञों की टीम एक घूमने वाला दरवाजा रख सकती है जो दक्षता को अधिकतम करती है और सहायता के लिए कभी भी कदम नहीं उठाती है (ऋण के निर्माण के जोखिम के लिए)।

एक ऐसी प्रणाली के निर्माण में जो अधिक अनुकूलनीय हो, जो अल्पकालिक रोजगार को गले लगा सके और उसका लाभ उठा सके, आप बाद में प्रभाव को कम कर देंगे यदि आप एक वरिष्ठ टीम सदस्य को खो देते हैं क्योंकि ज्ञान प्रक्रिया में अमर हो जाता है, लोगों में नहीं।

टैग, यू आर इट

आपको टैग खेलना किसने सिखाया? कोई फर्क नहीं पड़ता कि आप दुनिया में कहीं भी हैं, आपने शायद इस खेल को अन्य बच्चों से खेलना सीखा है। वयस्कों को बच्चों को टैग खेलना सिखाने की ज़रूरत नहीं है।

हम मेमों को मज़ेदार छवियों के रूप में सोचते हैं, लेकिन मेम की मूल परिभाषा एक संस्कृति या व्यवहार की प्रणाली का एक तत्व है जो एक व्यक्ति से दूसरे व्यक्ति को नकल या अन्य गैर-आनुवंशिक माध्यमों से पारित किया जाता है।

टैग एक मेम है। नियमों का मालिक कोई नहीं है। खेल में सुधार के लिए कोई जिम्मेदार नहीं है। वास्तव में, फ्रीज टैग जैसे वेरिएंट का समर्थन करते हुए नियम सरल हैं। इसके अलावा, इसे विभिन्न वातावरणों के लिए अनुकूलित किया जा सकता है। यह बच्चों के घूमने वाले दरवाजे के लिए डिज़ाइन किया गया है जो अंततः किशोरों में बदल जाते हैं जो बहुत अच्छे हैं।

टैग जैसे गेम के लिए बहुत कम सिस्टम डेट है। टैग की तुलना अन्य खेल के मैदानों से करें जिनमें अधिक खिलाड़ियों या अधिक उपकरणों की आवश्यकता होती है... ब्रिटिश बुलडॉग, डॉजबॉल, डक डक गूज, पुलिस 'एन रॉबर्स, रेड रोवर। हो सकता है कि आपने ये खेल खेले हों, शायद आपने नहीं। इन खेलों में थोड़ा अधिक सिस्टम ऋण होता है। अधिक नियम, अधिक उपकरण, या अधिक खिलाड़ियों का अर्थ है अधिक सुविधाकर्ताओं की आवश्यकता।

तो हम टैग की तरह कैसे काम कर सकते हैं?

1. लीवरेज सीनियर्स बार को कम करने के लिए। टैग खेलने या कल्पना देने के लिए सीनियर्स नहीं हैं। उनका लक्ष्य बार को कम करना है: लोग कैसे तेजी से प्रशिक्षण ले सकते हैं, और तेजी से मूल्य प्रदान कर सकते हैं? कम प्रभाव वाले जोखिम के साथ लगातार, वृद्धिशील और नियमित रिलीज कैसे हो सकते हैं? (*खांसी खांसी* DevOps, फुर्तीली)
2. प्रक्रियाओं का नक्शा तैयार करें, प्रवाह का नक्शा तैयार करें और चोक पॉइंट्स की पहचान करें: शायद समस्या सॉफ्टवेयर टीम की नहीं है। शायद यह एक समर्पित परीक्षण टीम की कमी नहीं है। हो सकता है कि समस्या ऊपर की ओर हो: व्यवसाय परस्पर विरोधी प्राथमिकताओं के साथ वितरण पाइपलाइन को ओवरलोड कर रहा है?
3. लोगों के लिए ब्रेक लेने के लिए ड्राइवर क्या है? ब्रेक लेने में कुछ भी गलत नहीं है - लेकिन वे अक्सर हताशा की एक अंतर्धारा पर आश्चर्यजनक संकेत होते हैं। कोई व्यक्ति कब और क्यों दूर जा रहा है, इस पर नज़र रखना बहुत जानकारीपूर्ण हो सकता है: हो सकता है कि वे दूर चले गए हों क्योंकि कोड को संकलित और परिनियोजित करने में कुछ समय लगता है। हो सकता है कि वे दूर चले गए हों क्योंकि उन्हें एक चुनौती के बारे में अधिक गहराई से सोचने की जरूरत है जिसका वे सामना कर रहे हैं। (यह कोई बुरी बात नहीं है, लेकिन क्या जटिलता को कम करने के लिए समस्या को तोड़ा जा सकता है?) हो सकता है कि वे दूर चले गए हों क्योंकि ग्राहक की आवश्यकता उन्हें निराश कर रही है। हो सकता है कि उन्हें हवा के लिए आने की आवश्यकता हो क्योंकि एक नई सुविधा एक नया स्वरूप मजबूर कर रही है या एक खराब धारणा का खुलासा कर रही है।
4. ब्रेक की कमी का निरीक्षण करें: समान रूप से बताना तब होता है जब कोई बहुत अधिक सिर झुकाए। वे दूर नहीं जा सकते - उनका ध्यान आवश्यक है। या तो इसका मतलब है कि किसी पर बहुत अधिक निर्भरता है, या कार्य और कार्यक्षेत्र को बहुत व्यापक रूप से परिभाषित किया गया है, या अंतर्निहित प्रणाली उससे कहीं अधिक जटिल है जितनी होनी चाहिए।
5. सरलीकरण की संस्कृति का निर्माण करें। यानी, आपके प्रबंधक, आपके वरिष्ठ, आपके इंटरमीडिएट - सभी को यह कहने का अधिकार होना चाहिए: "यह जितना होना चाहिए उससे कहीं अधिक जटिल है - हम इसे कैसे आसान बना सकते हैं?" फीडबैक लीजिए - खासकर जूनियर्स से। जूनियर्स को पर्याप्त महत्व नहीं दिया जाता है। उनके अनुभव की कमी समझने की गलती न करें इसका मतलब है कि वे भोले हैं। जूनियर्स हमेशा यह नहीं जानते होंगे कि बेहतर तरीके हैं, लेकिन वे इस बारे में बहुत स्पष्ट हैं कि वे अपनी ऊर्जा कहाँ खर्च करते हैं (और बर्बाद करते हैं)।
6. जब भी कोई सीनियर डिलीवरी में योगदान देता है, तो पता करें कि क्यों। हर एक। समय। उत्पाद में एक P0 बग के लिए तत्काल हॉट फिक्स की आवश्यकता होती है। निम्न-स्तरीय कोड में परिवर्तन की आवश्यकता है। एक ग्राहक को एक चर्चा की आवश्यकता थी। अधिकारियों को अद्यतन के लिए एक प्रस्तुतिकरण की आवश्यकता थी।

एक बढ़ता हुआ ज्वार सभी नावों को उठा लेता है। वरिष्ठों को ज्वार होना चाहिए, नावों का नहीं।

खुद के मरने से स्वर्ग मिलता है

मेरे पूरे करियर में एक मार्गदर्शक सिद्धांत यह समझना रहा है कि समस्या उत्पादकता को कैसे प्रभावित करती है। यह अधिक कुशल टीम बनाने के लिए नहीं बल्कि अधिक प्रभावशाली टीम बनाने के लिए है। उत्पाद प्रबंधकों के पास परिणाम मापने का मंत्र होता है, उत्पादन का नहीं। दक्षता मायने रखती है जब आप जानते हैं कि आप क्या कर रहे हैं, और आपको इसे तेजी से करने की आवश्यकता है। प्रभाव एक अनाकार, खराब परिभाषित, गतिशील लक्ष्य है। इसके लिए अनुकूलन की आवश्यकता है। यही कारण है कि सही तरीके से उपयोग किए जाने पर चुस्त सिद्धांत, ओकेआर, लीन और कानबन इतने शक्तिशाली हो सकते हैं।

सिस्टम-व्यापी परिणामों पर ध्यान केंद्रित करने और सिस्टम ऋण का भुगतान करने से मुझे विभिन्न तरीकों से प्रभावशाली होने का अवसर मिला है।

• SaaS व्यवसाय के लिए, प्रारंभिक पूर्व-बिक्री चरण से लेकर उत्पादन में कोड परिनियोजन तक सूप-टू-नट्स प्रक्रिया का मानचित्रण करना। बाधाओं की पहचान करने के लिए प्रत्येक चरण के परिप्रेक्ष्य से लीड और साइकिल समय को मापना। इसे एक प्रणाली के रूप में देखते हुए, हम तब पहचान सकते हैं कि कैसे बेहतर योग्यता, बेहतर अयोग्यता, और ग्राहक प्रकार के आधार पर बिक्री और कार्यान्वयन प्रक्रिया को कैसे और कब पुनर्गठित किया जाए। धक्का देने के बजाय काम खींचने के कानबन दृष्टिकोण को लागू करना, सख्त डब्ल्यूआईपी सीमाएं स्थापित करना (जबकि अभी भी सुस्त के लिए लेखांकन - गोल्डरैट के ड्रम-बफर-रोप सादृश्य देखें), और पूर्ण की परिभाषा को औपचारिक रूप देने से हमें वर्कफ़्लो में लगातार सुधार करने में सक्षम बनाया गया है। अंत में, एक अतिरिक्त सिद्धांत, इस मामले में, प्रक्रिया को उत्पादकता में बाधा डालने की अनुमति नहीं देना था। एक त्वरित ट्रैक बनाने में, जहां संभव हो वहां चीजें तेजी से आगे बढ़ सकती हैं (यानी "शॉर्टकट") लेकिन यह हमेशा विश्लेषण के साथ आता है कि आधारभूत प्रक्रिया कहां विफल रही (यानी सिस्टम ऋण का भुगतान।) यह सुव्यवस्थित कार्यान्वयन 6+ सप्ताह से 2 तक नीचे और एक स्व-प्रबंधित प्रणाली बन गई।
• जूनियर्स फर्स्ट फिलॉसफी के साथ स्टाफिंग ने मुझे 6 महीने में अपनी टीम के आकार को चौगुना करने की अनुमति दी। रैंप-अप समय को कम करके, और जूनियर की उत्पादकता के आसपास सीनियर टीम को केंद्रित करने का मतलब है कि हम अपरिहार्य को गले लगा सकते हैं और भविष्यवाणी कर सकते हैं। इस दृष्टिकोण ने किसी भी जूनियर को दो आकर्षक विकल्पों के साथ अपने 2-वर्ष के निशान को पार करने के लिए छोड़ दिया: एक अधिक मध्यवर्ती भूमिका में स्नातक जहां उनका ध्यान जूनियर्स को सक्षम करने की ओर स्थानांतरित हो गया क्योंकि वे अपने कौशल को विकसित करना जारी रखते थे, या एक सौहार्दपूर्ण निकास पर टीम के साथ काम करते थे। इस पारदर्शिता ने करियर की अनिश्चितता का सामना करने पर जूनियर्स को होने वाली 2 साल की खुजली से निपटने में मदद की।
• संचालन और विकास टीमों को एक प्रक्रिया छतरी के नीचे लाना। इसने टीमों को संरेखित किया ताकि समानांतर वर्कस्ट्रीम के बजाय, यह गोलाकार हो: ऑपरेशन टीम का आउटपुट डेवलपमेंट टीम का इनपुट था। डेवलपमेंट टीम का आउटपुट ऑपरेशन टीम का इनपुट बन गया। रणनीतिक फीडबैक लूप के साथ "लिविंग" प्लेबुक को लागू करके, टीमें तेजी से आत्मनिर्भर बन गईं। इसने वरिष्ठ टीम को संचालन में शामिल होने से मुक्त कर दिया और लीड समय को 7+ महीने से घटाकर 3 सप्ताह कर दिया।
• सास विकास टीम के दृष्टिकोण को सॉफ्टवेयर विकास चरणों (परिभाषित करने, लागू करने, मान्य करने, जारी करने) से क्लाइंट-केंद्रित करने के लिए प्रभाव पर जोर देने के साथ-साथ काम को प्राथमिकता देते हुए जो पूरा होने के सबसे करीब है। इसने डिलीवरी टीमों को प्रभाव और प्राथमिकताओं की बेहतर समझ रखने में सक्षम बनाया और व्यवसाय को कम प्रभाव वाले काम / ग्राहकों के बारे में अधिक जागरूक और आलोचनात्मक होने की अनुमति दी।
• निर्माण और परिनियोजन समय में कटौती करके पुनरावृत्त विकास प्रक्रिया को सुव्यवस्थित करने में निवेश। यह उन "अवलोकन ब्रेक" क्षणों में से एक था जहां टीम अक्सर लंबी निर्माण/तैनाती प्रक्रिया की असहायता के कारण दूर हो जाती थी। महत्वपूर्ण रूप से, फिक्स पूरी तरह से तकनीकी नहीं था - बल्कि एक प्रक्रिया आधारित था। एक नई प्रक्रिया स्थापित करके, वितरण दल 200% अधिक उत्पादक बन गए।
• प्रक्रिया अक्षमताओं के लिए सॉफ्टवेयर का निर्माण नहीं करना। दिलचस्प समस्याओं को हल करने के लिए मुझे कोड लिखना जितना पसंद है, नया कोड अंतिम उपाय होना चाहिए। भले ही कोड का कोई शॉर्टकट न हो, और स्वयं का कोई तकनीकी ऋण न हो, कोड को बनाए रखने की आवश्यकता होती है। आपने अधिक सिस्टम ऋण पेश किया है - और समस्या की जड़ को संबोधित नहीं किया है। ये मामले बड़े पैमाने पर हैं और इन्हें आसानी से अनदेखा कर दिया जाता है - लेकिन वे फर्श पर एक बाल्टी रखकर छत के रिसाव को हल करने के बराबर हैं। मूल समस्या का समाधान करके इन सुधारों को समाप्त करने से अथाह क्षमताएँ पैदा होती हैं और टीम को उन मामलों पर काम करने में सक्षम बनाता है जो मायने रखती हैं।

लेकिन मैं सिर्फ एक मध्य-स्तरीय प्रबंधक हूं, मैं एक संगठन-व्यापी परिवर्तन कैसे लागू कर सकता हूं?

मैंने पहले लिखा था कि स्थानीय प्रयास केवल इतना आगे बढ़ते हैं और मैं उस पर कायम हूं। जब पूरा संगठन अधिक कुशल होने के तरीके पर एक आलोचनात्मक नज़र डालता है, तो आपको वास्तविक सुधार दिखाई देता है। स्थानीय प्रयास केवल इतना आगे बढ़ते हैं - लेकिन वे दूर हो जाते हैं, और जब वे करते हैं, तो वे अपने साथ प्रभाव की राजधानी लाते हैं।

टेक-अवे

मैं इन अंतिम सिद्धांतों के साथ अपनी बात समाप्त करूंगा:

1. सिस्टम ऋण किसी भी व्यावसायिक शॉर्टकट (सॉफ़्टवेयर, डिज़ाइन, प्रक्रिया या अन्यथा) के लिए अर्जित होता है। यह अपने आप में ठीक है।
2. बहुत अधिक कर्ज एक बुरी चीज है और इसके लिए निरंतर और जानबूझकर भुगतान करने की आवश्यकता होती है।
3. यह भुगतान सीनियर टीम द्वारा किया जाना चाहिए। वरिष्ठ टीम को इस बात पर भी ध्यान देना चाहिए कि भविष्य के ऋण को जोखिम से कैसे हटाया जाए (पहले स्थानीय अक्षमताओं की तलाश करके, फिर सिस्टम-व्यापी अक्षमताओं को देखकर)। सीनियर्स को डिलिवरेबल्स पर काम नहीं करना चाहिए, लेकिन जब वे ऐसा करते हैं तो यह एक बार होना चाहिए। फीडबैक लूप स्थापित करें जो पूछें "यह क्यों जरूरी था और हम इसे भविष्य में कैसे रोक सकते हैं?"
4. सिस्टम ऋण स्वास्थ्य का एक अच्छा उपाय ऑनबोर्डिंग आपकी जूनियर टीम के स्वास्थ्य को देखना है। अपनी जूनियर टीम को 18 महीने बाद छोड़ने की योजना बनाएं। ठीक है। उन्हें जल्द से जल्द कुशल बनाने के लिए वरिष्ठ टीम को सक्षम करें।
5. समस्याओं की पहचान करने के लिए जूनियर टीम की आवाज बुलंद करें। यहां तक कि भोली समस्याएं भी अधिक गंभीर समस्या का संकेत देती हैं ("मुझे अपना ईमेल पता कब मिलेगा?"; "मैं परीक्षण डेटा कैसे प्राप्त कर सकता हूं?"; "हमारी टीम क्या करती है?"; "मैंने अभी स्रोत कोड पकड़ा है, और मुझे बिल्ड त्रुटियां मिल रही हैं।")
6. 18 महीने के बाद किसी भी भूमिका में किसी भी व्यक्ति को छोड़ने की योजना बनाएं। यह भी ठीक है। प्रक्रियाओं और पाइपलाइन के निर्माण पर काम करने के लिए वरिष्ठ टीम होनी चाहिए जो व्यवधानों के बावजूद निरंतर वितरण को सक्षम बनाती है। उन्हें आत्मनिर्भर प्रक्रियाओं, स्व-प्रबंधन और स्व-संगठित टीमों का निर्माण करना चाहिए। जूनियर टीम को अंततः काम से ऊब जाना चाहिए, क्योंकि यह दोहराव हो जाता है। टीम के सदस्यों को लगातार और सक्रिय रूप से खुद को बेमानी और अनावश्यक बनाना चाहिए।
7. उन लोगों के लिए योजना बनाएं जो 18 महीने से अधिक समय तक रहेंगे। खुद को बेमानी बनाने के लिए काम करने के बावजूद, आप उस काम से कभी नहीं भागेंगे जो दक्षता को बढ़ाता है। एक कैरियर फ्रेमवर्क को परिभाषित करें जो जूनियर्स को इंटरमीडिएट, इंटरमीडिएट को सीनियर्स तक बढ़ाता है जो परिणाम-केंद्रित क्षमता के साथ संरेखित करता है।
8. पहले दिन के साथ ऐसा व्यवहार करें जैसे कि वह आखिरी दिन हो: काम के पहले दिन, कर्मचारियों के पास इस बात का सबसे अच्छा दृष्टिकोण होता है कि उसे जहाज पर क्या करना चाहिए। उन्हें सोचना चाहिए: मेरे जाने के बाद अगर कोई और शामिल हो जाए, तो इसे कैसे सुधारा जा सकता है?
9. नियमित रूप से मूर्खतापूर्ण प्रश्न ही बैठकें करें। लोगों को अपने सबसे बेवकूफी भरे सवालों को (गुमनाम रूप से) सबमिट करने दें। आप इस तरह से सबसे बड़ा ज्ञान अंतराल (और समस्याएं) पाएंगे। इन्हें संबोधित किया जाना चाहिए।
10. नियमित 'पे डाउन' मीटिंग शेड्यूल करें: सीनियर टीम को एक साथ लाएं और अक्षमताओं को देखें। उनके प्रभाव की लागत। उनके संकल्प की लागत। (यह सूची यही कारण है कि आपकी वरिष्ठ टीम का काम कभी खत्म नहीं होगा।)
11. Agile का सबसे महत्वपूर्ण हिस्सा इसकी अनुकूलन क्षमता है। बार-बार समायोजित करें। फीडबैक लूप हों। जो चीज पहले काम कर रही थी वह हमेशा काम नहीं करेगी। यह कोई समस्या नहीं है - यह आदर्श है। जो कोई भी निरंतर परिवर्तन और प्रयोग के लिए प्रतिरोधी है, वह समस्या का एक बड़ा हिस्सा है जितना वे समझते हैं।
12. अंत में, और शायद सबसे महत्वपूर्ण: यह एक 'टीम' अभ्यास नहीं है। यह एक कंपनी-व्यापी अभ्यास होना चाहिए। जबकि आप अपनी टीम के भीतर स्थानीय दक्षताओं को बढ़ा सकते हैं, वे केवल इतना ही आगे बढ़ेंगे। ऐसा कहा जा रहा है, यदि आप एक संगठन-व्यापी दृष्टिकोण को प्रभावित करने की स्थिति में नहीं हैं, तो अपने प्रबंधक से खरीद लें, और फिर अपनी टीमों के आसपास चार्टर्स बनाएं जो आपकी टीम को बाहरी कारकों से बचाए। अपने छोटे सिस्टम के दायरे, उसके इनपुट और आउटपुट को परिभाषित करने के लिए अपने प्रबंधक के साथ काम करें, और अपने सिस्टम ऋण का मूल्यांकन, विकास और भुगतान करने की आपकी योजना के बारे में उनका साइन-ऑफ प्राप्त करें।

बस इतना ही! (उन्होंने अपना सबसे लंबा लेख लिखने की पूरी विडंबना को स्वीकार करते हुए लिखा।)